DS-CD ROM 2 1993 August

home *** CD-ROM | disk | FTP | other *** search

/ DS-CD ROM 2 1993 August / DS CD-ROM 2.Ausgabe (August 1993).iso / programm / ds0045 / mbmtexte.exe / MBMPAKET.DOC < prev next >

Wrap

Text File | 1992-03-24 | 49KB | 915 lines

Anleitung zum Maus/Button/Menü Paket für Turbo-Pascal 5.X / 6.X Version 4.1 (C) 1990-1992 BY UWE KUHRING Kontakt: Uwe Kuhring Scheidter Str. 281 6602 Dudweiler Saar Tel.: 06897/768039 Postgiroamt Saarbrücken BLZ 590 100 66 KNR 522 56 667 Registrierungsgebühr siehe "PREISE.DOC" **************************************************************************** * ACHTUNG - WICHTIGE ZUSATZINFORMATION * * Dies ist die SHARE-Version des MBM-Pakets V4.1 * * Da ich Ihnen hierzu trotzdem die Original-Anleitung der Vollversion zur * * Durcharbeitung zur Verfügung stellen möchte, werde ich die Abweichungen * * zur registrierten Version hier kurz aufführen. * * Der folgende Absatz zum Kopierverbot verliert seine Gültigkeit. * * In der Share-Version fehlen die 4 Sources-Codes der 4 Units. * * Die Units wurden folgendermaßen eingeschränkt: * * Unit MOUSELIB => keine Einschränkung * * Unit BUTLIB => keine Einschränkung * * Unit MENULIB => keine Einschränkung * * Unit WINLIB => keine Einschränkung * * Die kommerzielle Nutzung dieses Programmpaketes wird erst durch den * * Vorgang der Registrierung vom Autor freigegeben. Sie können jedoch alle * * Prozeduren und Units in eigene Programme einbauen und gebührenfrei * * erproben. Vor dem Verkauf dieser Programme müssen Sie sich registrieren * * lassen, sonst vertreiben Sie mit Ihren Programmen letztlich Raubkopien! * **************************************************************************** Zum Urheberrecht: Mit dem Erwerb dieser Vollversion 4.1 des MBM-Pakets haben Sie ein preisgünstiges Programm zur Gestaltung graphischer Benutzeroberflächen in Turbo-Pascal erworben. Bitte beachten Sie aber, daß es sich bei diesem Programm, obwohl es vielleicht der Preis und die Mitlieferung der Sourcecodes erwarten lassen, nicht um Public-Domain, sondern um Copyright-geschützte Software handelt. Sie dürfen die Routinen benutzen, Ihren Erfordernissen anpassen und sie in Ihre Programme einbinden. Diese Programme können Sie frei verkaufen, ohne daß Lizenzabgaben entstehen. Untersagt bleibt jedoch die Weitergabe in unkompilierter Form (Source-Codes). Auch wenn Sie sich entscheiden, bei Ihrem Produkt den Source-Code mit- zuliefern, dürfen Sie die Source-Codes des MBM-Pakets nicht hinzufügen! WICHTIG: Als Source-Codes werden hier auch die .TPU Versionen der Libraries verstanden! Obwohl diese ein Compilat darstellen, sind Sie separat verwend- bar und bilden so den wesentlichen Teil dieses Programmpaketes. Nur Ihre .EXE oder .COM Dateien dürfen die Libraries des MBM-Paketes beim Verkauf enthalten! Zu den BGI und CHR Dateien: Nach Rücksprache mit Borland habe ich erfahren, daß es keine Probleme gibt, wenn Sie diese Dateien mit Ihren TP-Programmen ZUSAMMMEN verkaufen. Diese Programme müssen jedoch einen Hinweis daraufhin enthalten, daß das Copyright der BGI und CHR Dateien bei Borland liegt. Diesen Hinweis erteile ich hiermit. Der Verkauf einzelner BGI's und CHR's ist also NICHT zulässig. Auch kann ich KEINE GARANTIE der Richtigkeit meiner Behauptung zur lizenskostenfreien Beigabe der BGI und CHR Dateien geben. Setzten Sie sich im Zweifelsfall besser selbst mit Borland in Verbindung. P.S.: Ab der Version 3.0 sind nur noch 3 BGI-Dateien als Beigabe enthalten. Die Verwendung von DRV_LINK.TPU (s.u.) ist eine bessere Lösung, als die Verwendung der separaten BGI-Dateien. Haftung: Ich übernehme keinerlei Haftung für Schäden, die durch die Benutzung des MBM-Paketes in irgendeiner Weise entstehen könnten. Insbesondere gebe ich keine Garantie der Verwendbarkeit und Funktions- fähigkeit der beschriebenen Prozeduren, auch wenn dieser Eindruck in der folgenden Beschreibung der Software entstehen sollte. Nun zu den Units und Prozeduren des MBM-Paketes: Unit Prozeduren davon öffentlich uses mouselib 7 7 graph butlib 7 5 graph,mouselib menulib 11 10 graph,mouselib winlib 9 8 graph,mouselib,butlib Das Maus/Button/Menü Paket bietet in vier Units insgesamt 30 Prozeduren, die sowohl den Betrieb der Maus unterstützen, als auch das Implementieren von Buttons und Menüleisten und Windows auf dem Grafikbildschirm erleichtern. Die Prozeduren übernehmen die gesamte Handhabung und die Verwaltung der Buttons, Menüleisten und Menüunterpunkte sowie der Windows. Systemanforderungen: 1. Eine Grafikkarte aus der Gruppe HGC/CGA/MCGA/EGA/VGA. 2. Eine (M)CGA-Karte muß den Grafikmodus #(5)4 darstellen können (HiRes). 3. Natürlich Turbo-Pascal, und zwar ab Version 5.0 (eventuell sind auch 4.X Versionen verwendbar, dies wurde nicht getestet) Dringend empfohlen wird ferner: 1. Eine Computermaus, dann aber auch unbedingt mit Treiber. 2. EGA und VGA Karten ermöglichen eine farbige Darstellung. 3. Zur Änderung der MOUSELIB (Source-Code) ist wegen den Assembler-Inline- Anweisungen eine Turbo-Pascal Version 6.X erforderlich (einz. Ausnahme!) DIE 4 UNITS SIND AUSSCHLIEßLICH IM GRAFIKMODUS EINSETZBAR! Die zum Grafikbetrieb erforderlichen .BGI Grafiktreiber gehören jetzt zum Lieferumfang, beachten Sie jedoch, daß das Copyright dieser Dateien bei Borland liegt. Das gleiche gilt für die Datei 'LITT.CHR'. Die BGI's und CHR's sollten im Hauptverzeichnis zu finden sein, ansonsten muß bei der Proze- dur der Grafikeinstellung (ENTER_DEFAULT_GRAPHMODE in der MOUSELIB) die Pfadangabe für die .BGI Dateien vorgegeben werden. Zu diesem Zweck muß beim Funktionsaufruf INITGRAPH der Leerstring gegen die Pfadangabe ersetzt werden. Eine bessere Alternative hierzu bietet ab der Version 3.0 das Unit 'DRV_LINK.TPU', welches mittels "uses drv_link" in Ihr Programm eingebunden werden kann. Dann sind stets alle verwendeten Grafiktreiber verfügbar und obige Probleme entfallen. Ihr Programm wird dadurch allerdings auch einige KByte länger werden. Ab der Version 3.0 wird die Datei 'LITT.CHR' in keinem Fall mehr benötigt, wodurch sich der Inhalt der Zusatz-Ordners auf die BGI Dateien beschränkt. Es folgt eine Beschreibung der vier Units. Auftretende Fehler werden in den Variablen MOUSEERROR/BUTTONERROR/MENUERROR/WINDOWERROR entsprechend gemeldet. Die Fehlercodes finden sich ganz am Ende dieser Beschreibung. Wichtig bleibt dabei anzumerken, daß sich die Variable MOUSEERROR durchaus auch nach einem Prozeduraufruf aus der Gruppe BUTLIB/MENULIB/WINLIB verändern kann, da diese ihrerseits die MOUSELIB benutzen! Die nun folgende Beschreibung erklärt alle Eigenschaften und Fähigkeiten des MBM-Paketes in den 1.X Versionen. Für Besitzer einer 2.0 Version folgt am Ende des Textes eine Beschreibung der zusätzlichen Möglichkeiten. Darauf folgen spezielle Hinweise zur Version ab 3.0 und höher. In den "*" Kommentaren werden wichtige Änderungen der Versionen ab 3.0 jedoch schon vorweggenommen. ****************************************************************************** ****************************************************************************** Unit MOUSELIB ------------- Folgende Prozeduren stehen zur Verfügung: *************************** * ENTER_DEFAULT_GRAPHMODE * *************************** Eigentlich hat diese Prozedur nichts in der MOUSELIB zu suchen - diese Library bot sich allerdings an, da sie von allen anderen Libraries benutzt wird. So steht die Prozedur überall zur Verfügung. Sie schaltet den Rechner in den Grafikbetrieb und wählt dabei einen für Menüs und Buttons günstigen Grafikmodus aus. Danach wird noch das Vorhandensein einer Maus überprüft. Sollte diese fehlen oder kein brauch- barer Grafikmodus zu finden sein, wird das GESAMTE PROGRAMM mit einer entsprechenden Meldung ABGEBROCHEN. Sie können natürlich auch eine eigene Prozedur verwenden, wenn z.B. ein Programmabbruch in diesen Fällen nicht erwünscht ist, oder Sie einen ganz bestimmten Grafikmodus auswählen wollen! * Versionen ab 3.0 erlauben auch den Betrieb ohne Maus. Das Programm wird in diesem Fall natürlich nicht abgebrochen. ************************************** * MOUSECHECK (var BUTTONS : integer) * ************************************** Überprüft zunächst, ob ein Grafikmodus ausgewählt wurde. Nur im Grafik- betrieb macht die Installation von Buttons und ihre Mausbedienung Sinn (falls man diesen komischen Blockcursor im Textmodus nicht als Mauszeiger huldigt, was mir eher schwer fällt). Ist dies nicht der Fall, enthält die Variable MOUSEERROR die Zuweisung -1. Ansonsten wird noch geprüft, ob überhaupt ein Maustreiber zur Verfügung steht. Falls nicht, wird MOUSEERROR -2 und die Bearbeitung abgebrochen. Wird hingegen ein Treiber gefunden, wird in BUTTONS die Anzahl der Knöpfe der installierten Maus und in mouseerror 0 übergeben. Im Fehlerfall enthält BUTTONS den gleichen Wert wie MOUSEERROR. Diese Prozedur übernimmt auch die Definition des Mauszeigers. Die dazu benötigten 32 Words werden in einem unübersehbaren Feld in der Prozedur MOUSECHECK definiert. Sie können die Werte ändern, um sich einen eigenen Zeiger zu definieren. * Wie bereits erwähnt, bricht das Programm ab der Version 3.0 NICHT ab, wenn keine Maus gefunden wurde. In diesem Fall enthält die globale Variable MOUSECHECKED den Wert 99, im anderen Fall die Anzahl der Knöpfe der Maus. *********** * MOUSEON * *********** Schaltet die Maus einmal ein. Wurde sie mehrfach ausgeschaltet, muß sie entsprechend oft wieder eingeschaltet werden, bis sie sichtbar wird. * Ist keine Maus vorhanden macht dieser Befehl - nichts. ************ * MOUSEOFF * ************ Schaltet die Maus einmal aus. Mehrmaliges Ausschalten wird gespeichert, was den Betrieb in Prozeduren wesentlich erleichtert. * Dieser Befehl (wie auch die folgenden) macht nichts, wenn keine Maus gefunden wurde. *********************************** * MOUSESTAT (var X,Y,B : integer) * *********************************** Übergibt in X die aktuelle X-Koordinate der Maus und in Y die aktuelle Y-Koordinate. B enthält einen Bitvektor, der sich aus den auf der Maus gedrückten Tasten zusammensetzt: linke Taste : bit 0 gedrückt = 1 ungedrückt = 0 rechte Taste : bit 1 gedrückt = 2 ungedrückt = 0 mittlere Taste : bit 2 gedrückt = 4 ungedrückt = 0 Die mittlere Taste steht nicht bei jedem System zur Verfügung. MOUSEERROR enthält die üblichen Fehlercodes oder 0. * Ist keine Maus vorhanden, enthält die Variable B stets 0 und in X und Y sind die Werte von GETMAXX und GETMAXY zu finden. **************************** * MOUSESET (X,Y : integer) * **************************** Dient zum Setzen der Maus an eine bestimmte Position auf dem Grafikbild- schirm. Dabei müssen sich X und Y in den durch GETMAXX und GETMAXY vorgegebenen Grenzen befinden. Tun sie das nicht, wird die Maus nicht bewegt und MOUSERROR erhält die Zuweisung -3. Zusätzlich zu diesem Fehlercode können die anderen zwei Maus-Fehlercodes auftreten. *************************************** * MOUSEWINDOW (X1,Y1,X2,Y2 : integer) * *************************************** Dient der Definition eines Fensters in das die Maus "eingesperrt" wird. X1,Y1 definieren die linke obere Ecke und X2,Y2 die rechte untere Ecke dieses Fensters. Dabei muß gelten: 0 <= X1(Y1) <= X2(Y2) <= GETMAXX(Y) Ansonsten wird MOUSEERROR -3. Die Fehlercode -1 und -2 können auch auftreten. MOUSEWINDOW (0,0,GETMAXX,GETMAXY) setzt das gesamte Grafik-Fenster. Das waren die Maus-Prozeduren. Mittels "uses mouselib" kann die Maus auch ohne die Button/Menu-Prozeduren verwendet werden, was umgekehrt nicht möglich ist. ******************************************************************************* ******************************************************************************* Unit BUTLIB ----------- Folgende Prozeduren stehen zur Verfügung: ************************************************************* * DEFBUTTON (P,B,X,Y : integer ; T : string ; S : boolean; * * C : char ; U : byte) * ************************************************************* Definiert die Position des Button B durch die Angabe der Koordinaten X und Y. B muß zwischen 1 und MAXBUTTONS liegen (default=64), während X und Y in den durch GETMAXX und GETMAXY definierten Grenzen liegen müssen. P definiert die Button-Ebene, der der Button angehören soll. In der vorliegenden Version stehen dazu 4 verschieden Ebenen (1..4) zur Verfügung. In T wird der in den Button einzutragende Text übergeben und wenn S wahr ist, wird der Button später schattiert gezeichnet werden. In der Variablen C wird ein zum Mausbetrieb alternativer Buchstabe angegeben. Später kann dieser Button über die Tastenkombination <ALT> <BUCHSTABE> angeklickt werden. Zulässig für C sind die Großbuchstaben 'A' bis 'Z' sowie die Zahlen '0' bis '9'. Soll diese Option nicht verwendet werden, muß C das Leerzeichen ' ' enthalten. U definiert schließlich die Nummer des zu unterstreichenden Buchstabens im Textstring. So können Sie dem Benutzer mitteilen, welche <ALT> <?> Kombination einen beliebigen Button anklickt. Lautet Ihr Button- text z.B. 'Exit' und ist C='X', kann der Exit-Button mit ALT X angeklickt werden. Dies solltem Sie dem Benutzer mitteilen, indem Sie das X unter- strichen darstellen (U=2). Wenn U=0 ist, wird kein Buchstabe unterstrichen. Wichtig: Der Button wird durch seine Definition noch nicht gezeichnet. Wichtig: BUTTONERROR -3 (ungültige Koordinaten) kann auch dann auftreten, wenn X und Y zulässige Werte enthalten. In diesem Fall würde der Text des Buttons den rechten Rand des Bildschirms überschreiten! Wichtig: Vergeben Sie auf einer Ebene nicht zweimal die gleiche <ALT> <?> Kombination zur Button-Aktivierung! Es würde stets nur der erste Button angeklickt werden können. ******************************** * DEFBUTTONPLANE (N : integer) * ******************************** Aktiviert eine Ebene des Button-Handlers. Alle definierten Buttons dieser Ebene werden nun gezeichnet. Der Bildschirm wird vorher NICHT automatisch gelöscht. Die verwendete Zeichenfarbe ist die eingestellte Zeichenfarbe. Alle Rückgaben der weiteren Prozeduren beziehen sich auf diese Ebene. ************************************************************************ * PRESSEDBUTTON (var BUTTON,MOUSEBUT : integer ; var SCAN_CHAR : char) * ************************************************************************ Liefert Informationen über die Position des Mauszeigers in der durch DEFBUTTONPLANE definierten Ebene. Enthält BUTTON 0, so befindet sich der Mauszeiger über keinem Button der definierten Ebene. Ansonsten enthält BUTTON die Nummer des Buttons, über dem der Mauszeiger "schwebt". MOUSEBUT erteilt darüber hinaus Information darüber, welche Maustasten zur Zeit gedrückt werden. Das Format ist das bei MOUSESTAT beschriebene. Soll auch die Tastaturbedienung des Buttonhändlers unterstützt werden, so muß in SCAN_CHAR das nach dem NUL-Zeichen gelesene Zeichen an die Routine übergeben werden. (Siehe auch MB_DEMO und "ERWEITERTE TASTATURCODES" im Turbo-Pascal Benutzerhandbuch.) Hat sich ein Button für dieses Zeichen in SCAN_CHAR für zuständig erklärt, wird BUTTON entsprechend und MOUSEBUT auf 1 gesetzt. SCAN_CHAR wird dann das Zeichen CHR(255) zugeschrieben, um die Abarbeitung zu kennzeichnen. ****************************** * REVERTBUTTON (N : Integer) * ****************************** Invertiert die Farbe des Buttons N in der aktuellen Ebene. Ein erneuter Aufruf dieser Funktion stellt den ursprünglichen Zustand wieder her. ***************************************************************** * DEFTEXTBUTTON (P,B,X,Y : integer ; T : string ; S : boolean; * * C : char ; U : byte) * ***************************************************************** Ist der Prozedur DEFBUTTON sehr ähnlich und ruft diese auch auf. Während DEFBUTTON jede Position auf dem Grafikbildschirm für die Instal- lation eines Buttons zuläßt, erzeugt die DEFTEXTBUTTON Prozedur eine Art GOTOXY mit anschließendem WRITE. Der Vorteil der ersten Funktion liegt in Ihrer beliebigen Anordnungs- möglichkeit der Buttons, ihr Nachteil in der schlechten Berechenbarkeit sinnvoller Positionen und vor allem die Abhängigkeit von der verwendeten Grafikkarte. Die zweite Prozedur ermöglicht hingegen eine "normalisierte" Ausgabe von Buttons auf dem Bildschirm. Allerdings wird ein Zeichensatz benötigt, der ein Bildschirmformat von 80x25 Zeichen ermöglicht. Dafür wird die Abhängigkeit von verwendeten Grafikkarten beseitigt. Entsprechend oberer Norm muß bei DEFTEXTBUTTON der Wert von Y zwischen 1 und 23 liegen (entsprechend den Zeilenzahlen 0..24) und der Wert von X zwischen 1 und 78 (entsprechend den Spaltenzahlen 0..79). Die ersten und letzten Zeilen (Spalten) können wegen der Button-Umrandung nicht genutzt werden. Des weiteren darf der Wert von X nicht so groß sein, daß mit dem Text das Zeilenende erreicht würde. Zwischen zwei Buttons sollte eine Leerzeile liegen, womit in eine Spalte maximal 12 Buttons passen. Zwar ist bei EGA/VGA Karten eine Anornung in jeder Zeile möglich, dies kann jedoch bei anderen Karten zu Überlappungen führen. Noch eine wichtige Anmerkung zum Zeichensatz: Die Wahl eines passenden Zeichensatzes kann u.U. recht mühsam sein. Der Aufruf der Prozedur ENTER_DEFAULT_GRAPHMODE, der in den Demoprogrammen obligatorisch ist, sollte stets zum Starten des Grafikmodus eingesetzt werden. Das waren alle 5 (öffentlichen) Prozeduren der BUTLIB. *********************** * CLEAR_EXIST_BUTTONS * *********************** Zusätzlich existiert in der BUTLIB noch diese Prozedur, die beim Start der BUTLIB dafür sorgt, daß alle Buttons zunächst als unbelegt gelten. Ein späterer Aufruf würde alle Buttons in einem Programm löschen, was keinen Sinn macht. Für verschiedene Menüs stehen schließlich verschiedene Ebenen zur Verfügung, wodurch eine Neudefinition einer Ebene unnötig wird. ******************* * INIT_SCAN_ARRAY * ******************* Auch diese Prozedur wird beim ersten Start des Units einmal aufgerufen. Sie stellt ein Link zwischen SCAN-CODES und ASCII-CODES her und ist durchaus erweiterbar. Sollten 4 Ebenen oder 64 Buttons pro Ebene nicht ausreichen, können diese Werte im Interface-Teil der BUTLIB erhöht werden. Dazu müssen nur die Konstanten MAXPLANES und MAXBUTTONS andere Zuweisungen erhalten. Die Größe der Werte von MAXPLANES und MAXBUTTONS wird nur durch den verfügbaren Speicher begrenzt. ***************************************************************************** ***************************************************************************** Unit MENULIB ------------ ************************* * CLR_ALL_MENUREGISTERS * ************************* Kennzeichnet alle Menüeintrage als unbelegt, also frei. Dies ist nötig, damit beim ersten MENUON nicht allerlei Unsinn in den Menüs erscheint. Die Prozedur kann jedoch auch problemlos zum endgültigen Löschen der gesamten Menüleiste benutzt werden. (Den Erstaufruf übernimmt das Unit selbst, ein CLR_ALL_MENUREGISTERS Befehl im Programm ist nicht nötig) ******************************* * CLR (X1,Y1,X2,Y2 : integer) * ******************************* Löscht einen rechteckigen Ausschnitt des Grafikbildschirmes. Ähnlich wie bei CLEARDEVICE wird dieser Teil mit der Hintergrungfarbe überschrieben. x1 und y1 definieren die linke obere und x2 sowie y2 die rechte untere Ecke dieses Ausschnittes. Diese Prozedur wird von den Prozeduren der Menügrafikdarstellung benutzt, kann jedoch auch von außen zum Löschen von Bildschirmteilen genutzt werden. ************************************************ * MENUREGISTER (X,Y : integer ; NAME : string) * ************************************************ Definiert den Namen des Eintrages in der Spalte X und der Zeile Y. Der später dort erscheinende Text wird in NAME übergeben. In der jetzigen Version werden maximal 7 Hauptmenüspalten zugelassen. Dementsprechend muß X zwischen 1 und 7 liegen, womit die X-te Spalte angesprochen wird. Y definiert hingegen die Position in der Spalte X, also die gewünschte Zeile. Es werden maximal 12 Einträge pro Hauptmenüpunkt zugelassen. So muß also Y zwischen 0 und 12 liegen. Mit 0 wird der Menü- oberbegriff (der Eintrag in der Hauptmenüzeile) definiert, liegt Y zwischen 1 und 12 dann die entsprechende Zeile im Menü selbst. Sowohl Hauptmenüpunkte als auch Unterpunkte können übersprungen werden, so kann z.B. der Hauptmenüpunkt Nr.7 als erster definiert werden. Ein Hauptmenüeintrag darf bis maximal 8 Zeichen, ein Untermenüeintrag jedoch bis zu 16 Zeichen lang sein. Wird in NAME ein Nullstring übergeben, wird der entsprechende Eintrag aus dem Menü gelöscht. ********** * MENUON * ********** Stellt das bis dato mittels MENUREGISTER definierte Menü auf dem Grafik- bildschirm dar. Dabei werden die oberen 4% des Bildschirmes ausgenutzt. Darunter liegende Informationen gehen verloren. Es werden (logischerweise) nur Hauptmenüpunkte dargestellt. So nützt es wenig, wenn alle 12 Untermenü- einträge eines Menüs definiert wurden, aber noch kein Hauptmenüeintrag. Dieses Menü erscheint nicht und wird später bei 'vernünftiger' Program- mierung unzugänglich bleiben. ACHTUNG: Sollte es aus irgendeinem Grund nötig sein, das Menü während seines Betriebes zu verändern, sollte zunächst MENUOFF mit anschließendem MENUON genutzt werden, um den gewünschten Effekt der Aktualisierung zu erreichen. *********** * MENUOFF * *********** Schaltete das aktuelle Menü vollständig ab. Die Menüleiste wird gelöscht und die meisten Menüprozeduren verweigern Ihren Dienst. Diese Aufrufe führen dann zu MENUERROR=-10 (Menü ist nicht eingeschaltet). ****************************** * MENUMARK (X,Y,Z : integer) * ****************************** Zusätzlich zum Menünamen kann im Menü eine Markierung des entsprechenden Eintrages erscheinen. Mit X und Y wird der gewünschte Eintrag, wie unter MENUREGISTER beschrieben, angesprochen. Z enthält eine Zahl zwischen 0 und 2, welche die gewünschte Markierungsart festlegt. 0 bedeutet dabei keine Markierung bzw. Markierung löschen, falls des Menü gerade heruntergeklappt ist. Diese Markierung (also keine Markierung) wird auch jedem neu definier- tem Eintrag als erstes zugewiesen. Ist Z=1 dann wird der Menüeintrag als unzugänglich gekennzeichnet. Dann erscheint links vom Menüeintrag das Symbol der leeren Menge, um diesen Zustand zu kennzeichnen. Ein solcher Eintrag ist nun tatsächlich aus dem Menü verschwunden. Zwar wird er beim Herunterklappen des Menüs noch angezeigt, aber die Prozedur MENUSTAT behandelt diesen Eintrag wie einen nicht definierten. Dieses Verhalten ermöglicht ein äußerst simples und effektives Verfahren, um von einem Programm eine Demo- version zu erzeugen: Es braucht nur ein wichtiger Menüeintrag nach seiner Definition als unzugänglich gezeichnet werden, schon ist es dem Anwender unmöglich, diesen Punkt aufzurufen. Dazu sollte noch aus dem entsprechenden Programmteil eine wichtige Zeile gelöscht werden. Schon diese zwei Aktionen liefern sowohl Betriebssicherheit, als auch relativ guten Schutz vor Hackern. Mit Z=2 wird ein Menüeintrag als aktiviert gekennzeichnet (mit einem Haken). Im Gegensatz zur vorherigen Markierung hat diese keinerlei Einfluß auf weitere Prozeduren und dient nur der Übersichtlichkeit. ************************** * MENUPULL (N : integer) * ************************** Klappt das mit N definierte Menü herunter. N muß zwischen 1 und 7 liegen und damit ein Menü beschreiben, welches mindestens 1 Eintrag enthalten muß. Ein nur aus seinem Namen bestehendes Menü kann nicht heruntergeklappt werden. Alle unter dem Menükasten liegenden Bildschirminformationen (das sind bis zu 16% des Bildschirmes) werden gesichert. Es werden alle definierten Einträge und Markierungen dieses Menüs sichtbar. Da immer nur ein Menü zur gleichen Zeit heruntergeklappt sein darf, führt diese Prozedur in dem Fall, daß bereits ein Menü heruntergeklappt ist, zunächst ein MENUPUSH aus und klappt anschließend das gewünschte Menü herunter. ************ * MENUPUSH * ************ Da stets höchstens ein Menü heruntergeklappt ist, ist eine weitere Angabe von Parametern für diese Prozedur unnötig. Die Prozedur klappt das momentan heruntergeklappte Menü wieder hoch. Die vor dem Herunterklappen des Menüs gesicherten Bildschirminformationen werden restauriert, womit der Bildschirm wieder so aussieht, wie vor dem Aufruf von MENUPULL. (Es sei denn, man verändert während ein Menü heruntergeklappt ist, den Bildschirm, was man tunlichst unterlassen sollte!) **************************************************************** * MENUSTAT (var X,Y,MOUSEBUT : integer ; var SCAN_CHAR : char) * **************************************************************** Liefert Informationen über die Positionen des Mauszeigers (der sichtbar sein sollte => MOUSEON benutzen) bezüglich des aktuell dargestellten Menüs. MOUSEBUT ist absolut funktionsgleich mit MOUSEBUT bei der MOUSELIB-Prozedur MOUSESTAT. SCAN_CHAR wird wie bei der PRESSED_BUTTON Routine in der BUTLIB zur Tastaturbedienung der Menüleiste benutzt. Sehen Sie sich bitte die Anleitung dieser BUTLIB-Prozedur nocheinmal an. Sie sollten aber auch unbedingt das kurze Kapitel über die erweiterten Tastaturcodes in den TP- Handbüchern lesen. Auch die Demo-Programme MB_DEMO und MENUDEMO zeigen, wie SCAN_CHAR verwendet werden kann. Nach dem Aufruf: Y und X geben die Zeile und Spalte wieder, über der sich der Mauszeiger zur Zeit befindet. Da nur die Spalten 1 bis 7 definiert sind, bedeutet eine 0 in X nach dem Aufruf dieser Prozedur, das sich die Maus über keinem anwählbaren Eintrag befindet. Dabei ist auch stets Y=0, woraus man leicht folgern kann: Dann und nur dann wenn (X+Y)>0 steht der Mauszeiger über einem anwählbaren Eintrag. Da man jedoch aus X=0 nur folgern kann, daß die Maus über keinem ANWÄHLBAREN Eintrag steht, kann man ein heruntergeklapptes Menü deshalb nicht einfach wieder hochklappen. Der Mauszeiger könnte auf einem leeren oder unzugänglichen Eintrag stehen und das Menü würde plötzlich verschwinden. In diesem Fall hilft die nach jedem Aufruf von MENUSTAT aktualisierte Variable MENULEFT, die immer dann wahr (true) ist, wenn sich der Mauszeiger über keinem Menükasten oder über einem nicht zum aktuell heruntergeklappten Menükasten gehörenden Menüpunkt befindet. In diesem Zusammenhang sollen einmal alle weiteren Variablen, die zusätzliche wichtige Informationen liefern können beschrieben werden: 1. MENUERROR : Fehlervariable, siehe Ende dieser Beschreibung. 2. MENULEFT : Ist im obigen Text gerade beschrieben worden. 3. MENUPULLED : Enthält die Nummer des gerade heruntergeklappten Menüs oder 0, wenn kein Menü heruntergeklappt ist. 4. REVERTED : Enthält die Nummer des gerade invertierten Menüuntereintrages oder 0, falls kein Untereintrag invertiert ist. 5. MENUVIEW : Ist wahr (true) wenn MENUON als letztes aufgerufen wurde, bzw. unwahr (false) nach MENUOFF oder dem Start des Units. 6. KEY_MODE : Ist wahr, wenn das aktuell heruntergeklappte Menu von der Tastatur aktiviert wurde und die Maus das Menü noch nicht übernommen hat. ********************************* * MENUREVERT (N,MODE : integer) * ********************************* Invertiert (kennzeichnet mit invertierten Farben) den Untereintrag mit der Nummer N im aktuell heruntergeklappten Menü. Dazu muß sowohl ein Menü heruntergeklappt sein, als auch der gewünschte Eintrag existieren, d.h. definiert sein. Da kein Haupteintrag invertiert werden kann, muß N zwischen 1 und 12 liegen. Es kann immer nur höchstens ein Eintrag invertiert sein. Wird mit N ein anderer als bereits im Menü invertierter Eintrag angegeben, so wird zunächst der alte Eintrag wieder auf 'normale' Färbung gebracht. Ist MODE=1 dann wird der Eintrag wie beschrieben durch Invertierung von den anderen Einträgen abgehoben. Ist MODE hingegen =0 wird der Eintrag wieder auf 'normale' Färbung gebracht. Während es bei MODE=1 wichtig ist, welcher Eintrag mit N gekennzeichet ist, ist bei MODE=0 diese Angabe durch Eindeutigkeit eigentlich unnötig. Trotzdem muß N den formalen Bedingungen genügen, ansonsten ist sein Inhalt nicht von Bedeutung. MENUREVERT(1,0) stellt also in jedem Fall den Menükasten wieder ohne Invertierungen dar. Das war die Beschreibung der 10 (öffentlichen) MENULIB-Prozeduren. ************************* * REVERT (N : integer); * ************************* Diese zusätzliche nicht-öffentliche Prozedur übernimmt den eigentlichen Invertiervorgang. Da diese Funktion weder Bereichsprüfungen vornimmt, noch irgendeinen weitergehenden Sinn hat, ist ihre Unterbringung im Implementationsteil am sinnvollsten. ******************************************************************************* ******************************************************************************* Verbesserungen in der Version 2.0 --------------------------------- Diese Version wurde in zweierlei Hinsicht erweitert. Zunächst können nun 16 Untermenüs verwaltet werden, anstatt nur maximal 12 Untermenüs. Die ganz wesentliche Erweiterung ist jedoch die Möglichkeit, Buttons und Menüs jetzt farbig zu gestalten. Die Programme des MBM-Paketes erkennen selbstständig die Grafik-Karte und stellen die Menüs und Buttons bei HGC, CGA und MCGA schwarz/weiß und bei EGA/VGA-Karten farbig dar. Dabei kann für jedes Untermenü bzw. jeden Button eine beliebige von 16 Farben ausgewählt werden. Falls Sie nun befürchten, Ihre Programme umschreiben zu müssen, um Farbe in die Menüs zu bekommen, kann ich Sie beruhigen. Es ist nämlich nicht notwendig die Programme umzuschreiben; nur wenn Sie eigene Farben setzen wollen, ist eine ERGÄNZUNG Ihrer Programme um eine oder zwei Prozeduren erforderlich, die anderen Prozeduren bleiben unverändert! Die Vorgehensweise: Wenn Sie die ENTER_DEFAULT_GRAPHMODE Prozedur der Mouselib verwenden, sind Ihre Menüs und Buttons bei EGA- und VGA-Karten automatisch farbig. Sollten Sie jedoch mit einer eigenen Routine den Grafik-Modus einschalten, müssen Sie die Variable VGA_EGA_CARD unbedingt selbst setzen. Sollte Ihr System über eine EGA- oder VGA-Karte verfügen, ist dazu die Anweisung VGA_EGA_CARD := true; ansonsten jedoch die Anweisung VGA_EGA_CARD := false; in die ersten Anweisungen Ihres Programmes (vor Menü- und Button-Aufrufen) einzufügen. Wird diese Zuweisung fortgelassen, ist der Inhalt der Variablen VGA_EGA_CARD nicht definiert und das MBM-Paket arbeitet fehlerhaft! Setzen Sie hingegen VGA_EGA_CARD grundsätzlich auf FALSE, dann arbeitet die Version 2.0 stets so, wie Ihre 1.X Vorgänger, also farblos. Benutzer der ENTER_DEFAULT_GRAPHMODE Prozedur können die Variable jedoch, wie bereits erwähnt, getrost vergessen. An den Parametern und Deklarationen der Prozeduren der drei Units ändert sich nichts. Die Farbe von Menüs und Buttons wird vielmehr über 2 Felder definiert. Da die Felder öffentlich sind, können sie Sie aus Ihrem Programm heraus manipulieren. Die Farbe von Menüs wird in dem Feld COLOR_ARRAY [A,B] definiert. A darf zwischen 0 und 7 liegen und bezeichnet im Falle von A=0 das Haupt- menü und im Falle von A=1 bis A=7 das entsprechende Untermenü. Mit B legen Sie fest, für welchen Teil der Anzeige Sie die Farbe definieren wollen: B=0 => Die Farbe für den Menühintergrund B=1 => Die Farbe für den Menürahmen B=2 => Die Farbe für die Menütexteinträge B=3 => Die Farbe für die Menümarkierungen Mit der Anweisung "COLOR_ARRAY [0,0] := 4 ;" legen Sie die Hintergrundfarbe des Haupmenüs auf Rot fest und mit "COLOR_ARRAY [5,3] := 14 ;" erreichen Sie, daß alle Markierungen des 5. Untermenüs in Gelb dargestellt werden. (Siehe auch TP-Handbuch unter Graph: Frabkonstanten). Die Farbe der Buttons wird ganz ähnlich gehandhabt, nur daß hier jeder Button seine eigene Farbe bekommen kann. Bei den Buttons ist es das Feld BUTTON_COLORS, welches die Farbinformation der Buttons beinhaltet. Eine mögliche Anweisung wäre: BUTTON_COLORS [A,B,C] := MEINE_FARBE ; wobei A die Buttonebene beschreibt und somit zwischen 1 und 4 liegen darf. B definiert den angesprochenen Button der Ebene A und C legt wieder fest, für welchen Teil des Buttons die Farbe gesetzt wird: C=0 => Die Farbe des Button-Hintergrundes C=1 => Die Farbe der Button-Umrahmung C=2 => Die Farbe des Button-Textes Beispiele: BUTTON_COLORS [1,1,0] := 6 ; BUTTON_COLORS [1,1,1] := 11 ; BUTTON_COLORS [1,1,2] := 7 ; Diese Kombination legt den Hintergrund des Buttons 1 der Ebene 1 auf braun, den Rahmen des Buttons auf helltürkis und die Textfarbe auf hellgrau fest. Es ist natürlich wichtig, daß Sie alle Farb-Definitionen der Buttons und Menüs vornehmen, BEVOR Sie sie anzeigen lassen, sonst wird immer die Standard-Farbe verwendet werden. Sollten noch immer Unklarheiten bestehen: Experimentieren Sie etwas mit den Programmen MB_DEMO.PAS und MENUDEMO.PAS und alles sollte klar werden. ******************************************************************************* ******************************************************************************* Verbesserungen in der Version 3.0 --------------------------------- Die völlig neu überarbeitete Version 3.0 enthält entscheidende Änderungen gegenüber ihren Vorgängern: 1. Der unschöne Vektorzeichensatz bei HGC/CGA/MCGA wird nicht mehr verwendet. Sollten bei diesen Karten eventuell einige Zeichen (ß,ä,ü,ö usw.) fehlen, so ist "GRAFTABL" (DOS-Befehl) vor dem (ersten) Programmstart von DOS aus aufzurufen. Noch besser ist der Einbau von "GRAFTABL" in Ihre AUTOEXEC.BAT Datei. 2. Das Unit "DRV_LINK.TPU" ermöglicht das Einbinden der 3 benötigten Grafik- treiber (BGI-Dateien) in jedes Turbo-Pascal Programm. 3. Eine Maus ist nicht erforderlich (aber wünschenswert), denn die Buttons und Menüs können auch über die Tastatur gesteuert werden. Somit erfolgt bei fehlender Maus kein Programmabbruch mehr. 4. Die Prozeduren der Mouselib nutzen die Möglichkeiten von Turbo-Pascal 6.0 zum direkten Einbinden von Assembler-Quell-Code. 5. Buttons sind nicht nur mit der Maus, sondern auch über <ALT> <?> Tastatur- kommandos zu aktivieren. Das Verfahren ist optional. 6. Die Daten des Buttonhandlers werden nun nicht mehr im Datensegment, sondern über Pointer dynamisch auf dem Heap verwaltet. Somit entfällt der unerfreuliche Zugriff des Buttonhandlers auf ca. 1/3 des Datenspeichers. 7. Hauptmenüs können über die Tastenkombination <ALT> <Fn> heruntergeklappt werden, wobei n zwischen 1 und 8 liegen muß und den gewünschten Hautein- trag angibt. Ist n=8 wird jedes Menü wieder eingeklappt. Ist ein Menü heruntergeklappt, kann mit den Cursortasten ein Eintrag ausgewählt und mit Return auch aktiviert werden. 8. Auch bei der Menübedienung hat die Maus Vorrang, d.h. man kann mit der Maus ein von der Tastatur aktiviertes Menü übernehmen. 9. Ein viertes Unit (WINLIB) ermöglicht das Abwickeln von Text-Ein/Ausgaben in Fenstern, woduch in Verbindung mit Buttons und Menüs keinerlei direkte Ausgabe von Texten auf dem Grafikbildschirm erforderlich ist. Dieser steht somit für Grafik (oder auch nur Hintergrund) zur Verfügung. Verbesserungen in der Version 3.1 --------------------------------- Einige Bugs (bzw. Unschönheiten) der Version 3.0 konnten beseitigt werden: 1. "WPRINT" (Winlib) mit einem leeren String funktioniert jetzt ordentlich, was bedeutet, daß nichts geschieht. Der Bildschirm wird in diesem Fall also nicht mehr mit einem wilden Muster gefüllt. 2. Wird "PRESSEDBUTTON" (Butlib) ohne Maustreiber und nur mit Tastatur- bedienung aufgerufen, wird nun "MOUSEBUT" auch auf Null gesetzt, wenn kein <RETURN> gedrückt wurde und nicht einfach der alte Wert zurück- geliefert. Das waren die Bugs - es folgen die beseitigten Unschönheiten: 1. Auch bei diesem Shareware-Programm kann man jetzt (wie bei meinen anderen Programmen) mit <ESC> ein Menü wieder hochklappen. 2. Die graue "Schriftunterlage" der Window-Überschriften wird im dem Fall, daß sie mit seitlichen Überständen zu lang würde, auf die Schriftgröße angepaßt und nicht einfach weggelassen. 3. Wird als Window-Überschrift ein Leerstring angegeben, wird jetzt nicht mehr ein kleines Stück "Schriftunterlage" in der oberen Leiste angezeigt, sondern die Umrandung des Fensters durchgehend gestaltet. Dazu kommen ein paar kleine Erweiterungen 1. Durch Setzen der Winlib-Variablen SCREEN_SAVE auf FALSE (Default = TRUE) können bel. große Fenster geöffnet werden. Das funktioniert deshalb, weil der Hintergrund dann NICHT gesichert wird. Daraus folgt aber auch, daß nach CLOSE_WINDOW der Bildschirm nicht wieder restauriert wird. Auf dem Bilschirm passiert sogar offensichtlich überhaupt nichts. Trotzdem muß CLOSE_WINDOW aufgerufen werden, damit die Window-Handle-Nummer wieder freigegeben werden kann. Diese Möglichkeit ist von Nutzen, wenn für ein Programm ein großes Fenster im Hintergrund geöffnet wird, welches bis zum Programmende nicht wieder geschlossen wird. Vergessen Sie nicht, die Variable SCREEN_SAVE nach dem Öffnen dieses Windows wieder auf TRUE zu setzen, damit sich die weiteren Fenster "normal" verhalten. 2. Das Programm MENUDEMO.EXE wurde leicht ergänzt. 3. Das neue Programm WINDEMO.EXE demonstriert ein wenig die Möglichkeiten der Winlib, allerdings mit SCREEN_SAVE = FALSE. Es wäre allerdings auch ziemlich unmöglich, mehrere tausend Window-Inhalte von Grafik-Windows zu speichern, ohne eine ganze Festplatte damit vollzupacken. Zur Version 3.2 --------------- Da beim aktuell verwendeten Zeichensatz bei HGC-Karten 90 Zeichen in eine Zeile passen, wurde in der Winlib auch die Möglichkeit eröffnet, Fenster mit einer Breite bis zu 88 Textzeichen zu öffnen. Die Text-Ausgabe in Windows erfolgt bei HGC-Karten dieser Option angepasst. Für alle anderen Grafik-Karten ändert sich jedoch nichts ! Zur Version 3.3 --------------- Man kann jetzt Fenster, die sich horizontal über den ganzen Bildschirm erstrecken, auch wieder schließen. Open_Window, Clear_Window und WPrint arbeiten ca. 3 mal so schnell wie in den vorherigen Versionen. Wird für den Rahmen die gleiche Farbe wie für den Fenster-Hintergrund angegeben, wird dieser nicht durch ein Muster hervorgehoben. Die Schattenfarbe der Buttons ist ab jetzt genau wie bei allen anderen Objekten schwarz. Geöffnete Menüs erzeugen ab dieser Version ebenfalls einen Schatten. Nach den Buttons wird nun auch der Speicherbedarf der Menulib teilweise dynamisch verwaltet. Dadurch gibt es aber auch einen neuen möglichen Fehlercode: -15 für "zuwenig Speicher". ******************************************************************************* ******************************************************************************* Die WINLIB der Versionen 3.X ---------------------------- ************************************************** * OPEN_WINDOW (X0,Y0,X1,Y1,C,B: integer ; * * var N : integer ; TITLE : string) * ************************************************** Öffnet ein Fenster mit der linken oberen Ecke in X0 und Y0 und der rechten unteren Ecke in X1 und Y1. Diese Koordinaten beschreiben Textpositionen und sind nicht etwa pixelorientiert. Außerdem definieren die Koordinaten die beschreibbare Fläche - die Umrandung ist jeweils 1 Zeichen breiter. Die X-Koordinaten müssen zw. 1 und 78 und die Y-Koordinaten zw. 1 und 23 liegen. C definiert die Rahmenfarbe und B die Farbe des Fensterhintergrundes. Die Prozedur liefert in N eine Nummer zurück, über die das Fenster in Zukunft angesprochen werden kann. Mit TITLE wird definiert, welche Überschrift das Fenster tragen soll. Es können maximal 10 Fenster gleichzeitig geöffnet sein. Die Fenster müssen in umgekehrter Öffnungsfolge wieder geschlossen werden, außer wenn jede Form von Fenster-Überlappung ausgeschlossen werden kann. ACHTUNG: Der unter einem Fenster liegende Hintergrund darf maximal 65000 Bytes Speicher zur Sicherung erfordern. Ist der Bedarf größer, wird das Fenster nicht geöffnet! Der maximale Speicherbedarf bei Karten bis VGA und bis 480*640 Pixel bei 16 Farben beträgt: (X1-X0+3)*(Y1-Y0+3)*80 Bytes, so daß bei diesen Karten ein einzelnes Fenster höchstens ca. 1/3 des Bildschirmes überdecken darf. ****************************** * CLOSE_WINDOW (N : integer) * ****************************** Schließt ein zuvor geöffnetes Fenster wieder. Die unter dem Fenster liegende Bildschirminformation wird dabei restauriert. Mit N muß der Prozedur die von OPEN_WINDOW zurückgelieferte Nummer übergeben werden. *********************************************** * WPRINT (N,X,Y,COLOR : integer ; S : string) * *********************************************** Gibt den Text im String S im Fenster mit der Nummer N aus. Der Text wird an den Positionen X und Y ausgegeben. Diese Koordinaten beziehen sich auf den Ursprung des Fensters und nicht etwa auf den des Bildschirmes. Somit ist bei einer späteren Verschiebung des Fensters keine Änderung der Ausgabe- befehle erforderlich. COLOR definiert die Farbe des Textes. Dieser muß in das Fenster "passen", sonst wird er nicht ausgegeben. ***************************************************** * WINPUT (N,X,Y,COLOR : integer ; var OUTS: string) * ***************************************************** Ermöglicht dem User im Fenster mit der Nummer N an den Positionen X und Y die Eingabe eines Textstringes. Der Textstring wird in der Farbe COLOR im Fenster dargestellt und in der Variablen OUTS an die aufrufende Prozedur übergeben. Auch Zahlen werden in einem String zurückgegeben. ****************************** * CLEAR_WINDOW (N : integer) * ****************************** Löscht den Inhalt des Fensters mit der Nummer N vollständig. Das Fenster wird also mit seiner definierten Hintergrundfarbe überschrieben. *************************** * WREVERT (N,Y : integer) * *************************** Invertiert im Fenster mit der Nummer N den Y. Eintrag in diesem Fenster auf voller Länge. Ein erneuter Aufruf der Funktion mit den gleichen Parametern stellt den ursprünglichen Zustand wieder her. ************************************************************************ * WINDOW_STAT (N : integer ; var Y,B : integer ; var SCAN_CHAR : char) * ************************************************************************ Erteilt der aufrufenden Prozedur Informationen über das Fenster mit der Nummer N. In Y wird mitgeteilt, über welchem Eintrag des Fensters sich der Mauszeiger befindet und B spiegelt den Status der Mausknöpfe im üblichen Format wieder. Damit dieser Vorgang auch ohne Maus über die Tastatur funktioniert, muß wie bei den anderen Libraries in SCAN_CHAR der 2. Wert des erweiterten Tastaturcodes oder CHR(13) übergeben werden. Das waren die öffentlichen Prozeduren der WINLIB. Zusätzlich verfügt auch die Winlib über eine CLR-Prozedur zum partiellen Löschen des Grafikbildschirmes. Diese Prozedur ist darüber hinaus ohne jede Bedeutung. ***************************************************************************** Veränderungen und Erweiterungen ab V4.0 ***************************************************************************** Zur Version 4.0 --------------- Am MBM-Paket selbst wurde (fast) nichts geändert: Daß der Mauszeiger nicht ganz sauber ist (oberer Teil der AND-Maske falsch definiert) gehört nun der Vergangenheit an. Wesentlicher ist die komplette Eingliederung der Sprite-Library V1.2 in das MBM-Paket. Diese Pascal-Routinen sind eigentlich weniger für schnellbewegte Sprites, als vielmehr für das Konstruieren und Anzeigen von Images von Bedeutung. Alles weitere entnehmen Sie bitte der Beschreibung für die Sprite-Library selbst. Da sich DRV_Link durchgesetzt hat, wurde ab der Version 4.0 vollständig auf die Beigabe der BGI-Treiber verzichtet. Wer Sie dennoch benutzen möchte, findet Sie auf den originalen Pascal-Disketten. Zur Version 4.1 --------------- Wesentlichster Grund für die Erstellung einer neuen Version war die Not- wendigkeit, meine neue Adresse in das Programm einzubauen. Damit jedoch auch ein echter Nutzen für den Anwender dabei herausspringt, wurde das Programm-Paket dabei gleich noch ein wenig ausgebaut. Die Winlib erhielt dabei eine neue Prozedur, die es dem Programmierer ermöglicht, dem Anwender schnell eine Mitteilung in einem Fenster zu übermitteln. Dazu muß nicht erst groß ein Fenster geöffnet und mit WPrint-Anweisungen beschrieben werden. Es geht viel einfacher: ********************************************** * INFO_WINDOW (C : char ; S1,S2,S3 : string) * ********************************************** Die Nummer des Windows ermittelt die Prozedur selbst. Das Fenster wird automatisch zentriert. Das Zeichen in C wird in der linken oberen Ecke des Fensters besonders hervorgehoben (z.B. ein "!" oder ein "?"). S1, S2 und S3 sind drei Strings von maximal je 30 Zeichen Länge, die im Fenster untereinander dargestellt werden. Der Anwender kann das Fenster durch Druck auf den "OK"-Button wieder schließen. Sie als Programmierer müssen sich dabei um nichts kümmern. Die Prozedur meldet sich erst nach der Quittierung durch den Anwender und dem automatischen Schließen des Info-Fensters in Ihrem Programm zurück. ---------------------------------------------------------------------------- Mit dem MBM-Paket V4.1 verfügen Sie über etliche Prozeduren, die die Erstellung von Programmen in Pascal für den Grafikmodus wesentlich erleichtern. Viel Spaß dabei. ***************************************************************************** ***************************************************************************** Hier kommen nun noch alle möglichen Fehlercodes: Error bei bei bei Nummer MOUSEERROR BUTTONERROR MENUERROR Beschreibung 0 ja ja ja kein Fehler -1 ja ja ja kein Grafikmodus aktiviert -2 ja ja ja kein Maustreiber installiert -3 ja ja ja unerlaubte Koordinatenangaben -4 nein ja nein unerlaubte Ebenen-Nr. angegeben -5 nein ja nein unerlaubte Button-Nr. angegeben -6 nein ja nein doppelte Button-Deklaration -7 nein ja nein keine aktuelle Ebene ausgewählt -8 nein nein ja unerlaubte Menü (X/Y) Position -9 nein nein ja Menüeintrag ist zu lang -10 nein nein ja Menü ist nicht eingeschaltet -11 nein nein ja kein Menüeintrag ist vorhanden -12 nein nein ja unerlaubter Markierungswert -13 nein nein ja kein Menü ist heruntergeklappt -14 nein nein ja unerlaubter Revertmodus -15 nein nein ja nur nach MENUPULL: kein Speicher Die Fehlercodes der WINLIB: windowerror Bedeutung 0 kein Fehler -1 ungültige Koordinaten -2 alle Fenster belegt (=> 10 Fenster offen) -3 kein Speicher (Fenster zu groß oder Heap voll) -4 unzulässiger Farbcode -5 unerlaubte Windownummer (wurde nicht vergeben) -6 Window ist nicht offen Hier endet die Beschreibung der 30 öffentlichen und der 4 nicht-öffentlichen Prozeduren der 4 Units MOUSELIB/BUTLIB/MENULIB/WINLIB des MBM-PAKETES V 4.1 Das wars - ich hoffe nicht zu ausführlich und nicht zu knapp. Und nun noch: Viel Erfolg.